Method and apparatus for indicating QoS of D2D data in wireless communication system

ABSTRACT

A method and apparatus for indicating quality of service (QoS) of device-to-device (D2D) data in a wireless communication system is provided. A first user equipment (UE) determines a value of a field in a header based on an identified QoS of the D2D data, and transmits to a second UE a layer 2 protocol data unit (PDU), which includes the header including the field having the determined value. Upon receiving the layer 2 PDU, the second UE identifies the QoS of the D2D data based on the value of the field in the header.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is the National Stage filing under 35 U.S.C. 371 ofInternational Application No. PCT/KR2015/001343, filed on Feb. 10, 2015,which claims the benefit of U.S. Provisional Application No. 61/937,626,filed on Feb. 10, 2014, the contents of which are all herebyincorporated by reference herein in their entirety.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to wireless communications, and moreparticularly, to a method and apparatus for indicating quality ofservice (QoS) of device-to-device (D2D) data in a wireless communicationsystem.

Related Art

Universal mobile telecommunications system (UMTS) is a 3rd generation(3G) asynchronous mobile communication system operating in wideband codedivision multiple access (WCDMA) based on European systems, globalsystem for mobile communications (GSM) and general packet radio services(GPRS). A long-term evolution (LTE) of UMTS is under discussion by the3rd generation partnership project (3GPP) that standardized UMTS.

The 3GPP LTE is a technology for enabling high-speed packetcommunications. Many schemes have been proposed for the LTE objectiveincluding those that aim to reduce user and provider costs, improveservice quality, and expand and improve coverage and system capacity.The 3GPP LTE requires reduced cost per bit, increased serviceavailability, flexible use of a frequency band, a simple structure, anopen interface, and adequate power consumption of a terminal as anupper-level requirement.

Recently, there has been a surge of interest in supportingproximity-based services (ProSe). Proximity is determined (“a userequipment (UE) is in proximity of another UE”) when given proximitycriteria are fulfilled. This new interest is motivated by severalfactors driven largely by social networking applications, and thecrushing data demands on cellular spectrum, much of which is localizedtraffic, and the under-utilization of uplink frequency bands. 3GPP istargeting the availability of ProSe in LTE rel-12 to enable LTE become acompetitive broadband communication technology for public safetynetworks, used by first responders. Due to the legacy issues and budgetconstraints, current public safety networks are still mainly based onobsolete 2G technologies while commercial networks are rapidly migratingto LTE. This evolution gap and the desire for enhanced services have ledto global attempts to upgrade existing public safety networks. Comparedto commercial networks, public safety networks have much more stringentservice requirements (e.g., reliability and security) and also requiredirect communication, especially when cellular coverage fails or is notavailable. This essential direct mode feature is currently missing inLTE.

As a part of ProSe, device-to-device (D2D) data may be transmittedbetween UEs. A method for indicating quality of service (Qos) of D2Ddata may be required.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for indicatingquality of service (QoS) of device-to-device (D2D) data in a wirelesscommunication system. The present invention provides a method foridentifying QoS of D2D data based on a value of a field in a header in alayer 2 protocol data unit (PDU).

In an aspect, a method for indicating, by a first user equipment (UE),quality of service (QoS) of device-to-device (D2D) data in a wirelesscommunication system is provided. The method includes identifying, bythe first UE, the QoS of the D2D data over a radio bearer, determining,by the first UE, a value of a field in a header based on the identifiedQoS, and transmitting, by the first UE to a second UE, a layer 2protocol data unit (PDU), which includes the header including the fieldhaving the determined value.

In another aspect, a method for identifying, by a second user equipment(UE), quality of service (QoS) of device-to-device (D2D) data in awireless communication system is provided. The method includesreceiving, by the second UE from a first UE, a layer 2 protocol dataunit (PDU), which includes a header including a field, over a radiobearer, and identifying, by the second UE, the QoS of the D2D data basedon a value of the field in the header.

A user equipment (UE) can properly handle received D2D data based on QOSof the received D2D data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows LTE system architecture.

FIG. 2 shows a block diagram of architecture of a typical E-UTRAN and atypical EPC.

FIG. 3 shows a block diagram of a user plane protocol stack of an LTEsystem.

FIG. 4 shows a block diagram of a control plane protocol stack of an LTEsystem.

FIG. 5 shows an example of a physical channel structure.

FIG. 6 shows reference architecture for ProSe.

FIG. 7 shows an example of one-step ProSe direct discovery procedure.

FIG. 8 shows an example of two-steps ProSe direct discovery procedure.

FIG. 9 to FIG. 12 show scenarios for D2D ProSe.

FIG. 13 shows an example of UE-NW relay functionality.

FIG. 14 shows an example of UE-UE relay functionality.

FIG. 15 shows an example of mapping between sidelink transport channelsand sidelink physical channels.

FIG. 16 shows an example of mapping between sidelink logical channelsand sidelink transport channels for ProSe direct communication.

FIG. 17 shows an example of a MAC PDU.

FIG. 18 to FIG. 20 show an example of a MAC PDU subheader.

FIG. 21 shows an example of a method for indicating QoS of D2D dataaccording to an embodiment of the present invention.

FIG. 22 shows a wireless communication system to implement an embodimentof the present invention.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

The technology described below can be used in various wirelesscommunication systems such as code division multiple access (CDMA),frequency division multiple access (FDMA), time division multiple access(TDMA), orthogonal frequency division multiple access (OFDMA), singlecarrier frequency division multiple access (SC-FDMA), etc. The CDMA canbe implemented with a radio technology such as universal terrestrialradio access (UTRA) or CDMA-2000. The TDMA can be implemented with aradio technology such as global system for mobile communications(GSM)/general packet ratio service (GPRS)/enhanced data rate for GSMevolution (EDGE). The OFDMA can be implemented with a radio technologysuch as institute of electrical and electronics engineers (IEEE) 802.11(Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), etc.IEEE 802.16m is an evolution of IEEE 802.16e, and provides backwardcompatibility with an IEEE 802.16-based system. The UTRA is a part of auniversal mobile telecommunication system (UMTS). 3rd generationpartnership project (3GPP) long term evolution (LTE) is a part of anevolved UMTS (E-UMTS) using the E-UTRA. The 3GPP LTE uses the OFDMA indownlink and uses the SC-FDMA in uplink. LTE-advance (LTE-A) is anevolution of the 3GPP LTE.

For clarity, the following description will focus on the LTE-A. However,technical features of the present invention are not limited thereto.

FIG. 1 shows LTE system architecture. The communication network iswidely deployed to provide a variety of communication services such asvoice over internet protocol (VoIP) through IMS and packet data.

Referring to FIG. 1, the LTE system architecture includes one or moreuser equipment (UE; 10), an evolved-UMTS terrestrial radio accessnetwork (E-UTRAN) and an evolved packet core (EPC). The UE 10 refers toa communication equipment carried by a user. The UE 10 may be fixed ormobile, and may be referred to as another terminology, such as a mobilestation (MS), a user terminal (UT), a subscriber station (SS), awireless device, etc.

The E-UTRAN includes one or more evolved node-B (eNB) 20, and aplurality of UEs may be located in one cell. The eNB 20 provides an endpoint of a control plane and a user plane to the UE 10. The eNB 20 isgenerally a fixed station that communicates with the UE 10 and may bereferred to as another terminology, such as a base station (BS), anaccess point, etc. One eNB 20 may be deployed per cell.

Hereinafter, a downlink (DL) denotes communication from the eNB 20 tothe UE 10, and an uplink (UL) denotes communication from the UE 10 tothe eNB 20. In the DL, a transmitter may be a part of the eNB 20, and areceiver may be a part of the UE 10. In the UL, the transmitter may be apart of the UE 10, and the receiver may be a part of the eNB 20.

The EPC includes a mobility management entity (MME) and a systemarchitecture evolution (SAE) gateway (S-GW). The MME/S-GW 30 may bepositioned at the end of the network and connected to an externalnetwork. For clarity, MME/S-GW 30 will be referred to herein simply as a“gateway,” but it is understood that this entity includes both the MMEand S-GW.

The MME provides various functions including non-access stratum (NAS)signaling to eNBs 20, NAS signaling security, access stratum (AS)security control, inter core network (CN) node signaling for mobilitybetween 3GPP access networks, idle mode UE reachability (includingcontrol and execution of paging retransmission), tracking area listmanagement (for UE in idle and active mode), packet data network (PDN)gateway (P-GW) and S-GW selection, MME selection for handovers with MMEchange, serving GPRS support node (SGSN) selection for handovers to 2Gor 3G 3GPP access networks, roaming, authentication, bearer managementfunctions including dedicated bearer establishment, support for publicwarning system (PWS) (which includes earthquake and tsunami warningsystem (ETWS) and commercial mobile alert system (CMAS)) messagetransmission. The S-GW host provides assorted functions includingper-user based packet filtering (by e.g., deep packet inspection),lawful interception, UE Internet protocol (IP) address allocation,transport level packet marking in the DL, UL and DL service levelcharging, gating and rate enforcement, DL rate enforcement based onaccess point name aggregate maximum bit rate (APN-AMBR).

Interfaces for transmitting user traffic or control traffic may be used.The UE 10 is connected to the eNB 20 via a Uu interface. The eNBs 20 areconnected to each other via an X2 interface. Neighboring eNBs may have ameshed network structure that has the X2 interface. A plurality of nodesmay be connected between the eNB 20 and the gateway 30 via an 51interface.

FIG. 2 shows a block diagram of architecture of a typical E-UTRAN and atypical EPC. Referring to FIG. 2, the eNB 20 may perform functions ofselection for gateway 30, routing toward the gateway 30 during a radioresource control (RRC) activation, scheduling and transmitting of pagingmessages, scheduling and transmitting of broadcast channel (BCH)information, dynamic allocation of resources to the UEs 10 in both ULand DL, configuration and provisioning of eNB measurements, radio bearercontrol, radio admission control (RAC), and connection mobility controlin LTE ACTIVE state. In the EPC, and as noted above, gateway 30 mayperform functions of paging origination, LTE_IDLE state management,ciphering of the user plane, SAE bearer control, and ciphering andintegrity protection of NAS signaling.

FIG. 3 shows a block diagram of a user plane protocol stack of an LTEsystem. FIG. 4 shows a block diagram of a control plane protocol stackof an LTE system. Layers of a radio interface protocol between the UEand the E-UTRAN may be classified into a first layer (L1), a secondlayer (L2), and a third layer (L3) based on the lower three layers ofthe open system interconnection (OSI) model that is well-known in thecommunication system.

A physical (PHY) layer belongs to the L1. The PHY layer provides ahigher layer with an information transfer service through a physicalchannel. The PHY layer is connected to a medium access control (MAC)layer, which is a higher layer of the PHY layer, through a transportchannel. A physical channel is mapped to the transport channel. Databetween the MAC layer and the PHY layer is transferred through thetransport channel. Between different PHY layers, i.e. between a PHYlayer of a transmission side and a PHY layer of a reception side, datais transferred via the physical channel.

A MAC layer, a radio link control (RLC) layer, and a packet dataconvergence protocol (PDCP) layer belong to the L2. The MAC layerprovides services to the RLC layer, which is a higher layer of the MAClayer, via a logical channel. The MAC layer provides data transferservices on logical channels. The RLC layer supports the transmission ofdata with reliability. Meanwhile, a function of the RLC layer may beimplemented with a functional block inside the MAC layer. In this case,the RLC layer may not exist. The PDCP layer provides a function ofheader compression function that reduces unnecessary control informationsuch that data being transmitted by employing IP packets, such as IPv4or IPv6, can be efficiently transmitted over a radio interface that hasa relatively small bandwidth.

A radio resource control (RRC) layer belongs to the L3. The RLC layer islocated at the lowest portion of the L3, and is only defined in thecontrol plane. The RRC layer controls logical channels, transportchannels, and physical channels in relation to the configuration,reconfiguration, and release of radio bearers (RBs). The RB signifies aservice provided the L2 for data transmission between the UE andE-UTRAN.

Referring to FIG. 3, the RLC and MAC layers (terminated in the eNB onthe network side) may perform functions such as scheduling, automaticrepeat request (ARQ), and hybrid ARQ (HARQ). The PDCP layer (terminatedin the eNB on the network side) may perform the user plane functionssuch as header compression, integrity protection, and ciphering.

Referring to FIG. 4, the RLC and MAC layers (terminated in the eNB onthe network side) may perform the same functions for the control plane.The RRC layer (terminated in the eNB on the network side) may performfunctions such as broadcasting, paging, RRC connection management, RBcontrol, mobility functions, and UE measurement reporting andcontrolling. The NAS control protocol (terminated in the MME of gatewayon the network side) may perform functions such as a SAE bearermanagement, authentication, LTE_IDLE mobility handling, pagingorigination in LTE_IDLE, and security control for the signaling betweenthe gateway and UE.

FIG. 5 shows an example of a physical channel structure. A physicalchannel transfers signaling and data between PHY layer of the UE and eNBwith a radio resource. A physical channel consists of a plurality ofsubframes in time domain and a plurality of subcarriers in frequencydomain. One subframe, which is 1 ms, consists of a plurality of symbolsin the time domain. Specific symbol(s) of the subframe, such as thefirst symbol of the subframe, may be used for a physical downlinkcontrol channel (PDCCH). The PDCCH carries dynamic allocated resources,such as a physical resource block (PRB) and modulation and coding scheme(MCS).

A DL transport channel includes a broadcast channel (BCH) used fortransmitting system information, a paging channel (PCH) used for paginga UE, a downlink shared channel (DL-SCH) used for transmitting usertraffic or control signals, a multicast channel (MCH) used for multicastor broadcast service transmission. The DL-SCH supports HARQ, dynamiclink adaptation by varying the modulation, coding and transmit power,and both dynamic and semi-static resource allocation. The DL-SCH alsomay enable broadcast in the entire cell and the use of beamforming.

A UL transport channel includes a random access channel (RACH) normallyused for initial access to a cell, a uplink shared channel (UL-SCH) fortransmitting user traffic or control signals, etc. The UL-SCH supportsHARQ and dynamic link adaptation by varying the transmit power andpotentially modulation and coding. The UL-SCH also may enable the use ofbeamforming.

The logical channels are classified into control channels fortransferring control plane information and traffic channels fortransferring user plane information, according to a type of transmittedinformation. That is, a set of logical channel types is defined fordifferent data transfer services offered by the MAC layer.

The control channels are used for transfer of control plane informationonly. The control channels provided by the MAC layer include a broadcastcontrol channel (BCCH), a paging control channel (PCCH), a commoncontrol channel (CCCH), a multicast control channel (MCCH) and adedicated control channel (DCCH). The BCCH is a downlink channel forbroadcasting system control information. The PCCH is a downlink channelthat transfers paging information and is used when the network does notknow the location cell of a UE. The CCCH is used by UEs having no RRCconnection with the network. The MCCH is a point-to-multipoint downlinkchannel used for transmitting multimedia broadcast multicast services(MBMS) control information from the network to a UE. The DCCH is apoint-to-point bi-directional channel used by UEs having an RRCconnection that transmits dedicated control information between a UE andthe network.

Traffic channels are used for the transfer of user plane informationonly. The traffic channels provided by the MAC layer include a dedicatedtraffic channel (DTCH) and a multicast traffic channel (MTCH). The DTCHis a point-to-point channel, dedicated to one UE for the transfer ofuser information and can exist in both uplink and downlink. The MTCH isa point-to-multipoint downlink channel for transmitting traffic datafrom the network to the UE.

Uplink connections between logical channels and transport channelsinclude the DCCH that can be mapped to the UL-SCH, the DTCH that can bemapped to the UL-SCH and the CCCH that can be mapped to the UL-SCH.Downlink connections between logical channels and transport channelsinclude the BCCH that can be mapped to the BCH or DL-SCH, the PCCH thatcan be mapped to the PCH, the DCCH that can be mapped to the DL-SCH, andthe DTCH that can be mapped to the DL-SCH, the MCCH that can be mappedto the MCH, and the MTCH that can be mapped to the MCH.

An RRC state indicates whether an RRC layer of the UE is logicallyconnected to an RRC layer of the E-UTRAN. The RRC state may be dividedinto two different states such as an RRC idle state (RRC_IDLE) and anRRC connected state (RRC_CONNECTED). In RRC₁₃ IDLE, the UE may receivebroadcasts of system information and paging information while the UEspecifies a discontinuous reception (DRX) configured by NAS, and the UEhas been allocated an identification (ID) which uniquely identifies theUE in a tracking area and may perform public land mobile network (PLMN)selection and cell re-selection. Also, in RRC_IDLE, no RRC context isstored in the eNB.

In RRC_CONNECTED, the UE has an E-UTRAN RRC connection and a context inthe E-UTRAN, such that transmitting and/or receiving data to/from theeNB becomes possible. Also, the UE can report channel qualityinformation and feedback information to the eNB. In RRC_CONNECTED, theE-UTRAN knows the cell to which the UE belongs. Therefore, the networkcan transmit and/or receive data to/from UE, the network can controlmobility (handover and inter-radio access technologies (RAT) cell changeorder to GSM EDGE radio access network (GERAN) with network assistedcell change (NACC)) of the UE, and the network can perform cellmeasurements for a neighboring cell.

In RRC_IDLE, the UE specifies the paging DRX cycle. Specifically, the UEmonitors a paging signal at a specific paging occasion of every UEspecific paging DRX cycle. The paging occasion is a time interval duringwhich a paging signal is transmitted. The UE has its own pagingoccasion. A paging message is transmitted over all cells belonging tothe same tracking area. If the UE moves from one tracking area (TA) toanother TA, the UE will send a tracking area update (TAU) message to thenetwork to update its location.

Proximity-based services (ProSe) are described. It may be referred to3GPP TR 23.703 V1.0.0 (2013-12) and/or 3GPP TR 36.843 V1.0.0 (2013-11).ProSe may be a concept including a device-to-device (D2D) communication.Hereinafter, “ProSe” may be used by being mixed with “D2D”.

ProSe direct communication means a communication between two or more UEsin proximity that are ProSe-enabled, by means of user plane transmissionusing E-UTRA technology via a path not traversing any network node.ProSe-enabled UE means a UE that supports ProSe requirements andassociated procedures. Unless explicitly stated otherwise, aProSe-enabled UE refers both to a non-public safety UE and a publicsafety UE. ProSe-enabled public safety UE means a ProSe-enabled UE thatalso supports ProSe procedures and capabilities specific to publicsafety. ProSe-enabled non-public safety UE means a UE that supportsProSe procedures and but not capabilities specific to public safety.ProSe direct discovery means a procedure employed by a ProSe-enabled UEto discover other ProSe-enabled UEs in its vicinity by using only thecapabilities of the two UEs with 3GPP LTE rel-12 technology. EPC-levelProSe discovery means a process by which the EPC determines theproximity of two ProSe-enabled UEs and informs them of their proximity.ProSe UE identity (ID) is a unique identity allocated by evolved packetsystem (EPS) which identifies the ProSe enabled UE. ProSe application IDis an identity identifying application related information for the ProSeenabled UE. They can exist more than one ProSe application IDs per UE.

Two different modes for ProSe direct communication are supported:

-   1. Network independent direct communication: This mode of operation    for ProSe direct communication does not require any network    assistance to authorize the connection and communication is    performed by using only functionality and information local to the    UE(s). This mode is applicable:    -   only to pre-authorized ProSe-enabled public safety UEs,    -   regardless of whether the UEs are served by E-UTRAN or not,    -   to both ProSe direct communication one-to-one and to ProSe        direct communication one-to-many.-   2. Network authorized direct communication: This mode of operation    for ProSe direct communication always requires network assistance by    the EPC to authorize the connection. This mode of operation applies:    -   to ProSe direct communication one-to-one,    -   when both UEs are served by E-UTRAN, and    -   for public safety UEs it may apply when only one UE is served by        E-UTRAN.

It has been identified that the following models for direct discoverymay exist.

-   1. Mode A (“I am here”): This model defines two roles for the UEs    that are participating in direct discovery.    -   Announcing UE: The UE announces certain information that may be        used from UEs in proximity that have permission to discover.    -   Monitoring UE: The UE that receives certain information that is        interested in from other UEs in proximity.

In this model, the announcing UE broadcasts the discovery messages atpre-defined discovery intervals and the UEs that are interested in thesemessages read them and process them. It is equivalent to “I am here”since the announcing UE would broadcast information about itself, e.g.its ProSe application IDs or ProSe UE IDs in the discovery message.

-   2. Model B (“who is there”/“are you there”): This model defines two    roles for the UEs that are participating in direct discovery.    -   Discoverer UE: The UE transmits a request containing certain        information about what is interested to discover.    -   Discoveree UE: The UE that receives the request message can        respond with some information related to the discoverer's        request.

It is equivalent to “who is there/are you there” since the discoverer UEsends information about other UEs that would like to receive responsesfrom, e.g. the information can be about a ProSe application IDcorresponding to a group and the members of the group can respond.

FIG. 6 shows reference architecture for ProSe. Referring to FIG. 6, thereference architecture for ProSe includes E-UTRAN, EPC, a plurality ofUEs having ProSe applications, ProSe application server, and ProSefunction. The EPC represents the E-UTRAN core network architecture. TheEPC includes entities such as MME, S-GW, P-GW, policy and charging rulesfunction (PCRF), home subscriber server (HSS), etc. The ProSeapplication servers are users of the ProSe capability for building theapplication functionality. In the public safety cases, they can bespecific agencies (PSAP), or in the commercial cases social media. Theseapplications rare defined outside the 3GPP architecture but there may bereference points towards 3GPP entities. The application server cancommunicate towards an application in the UE. Applications in the UE usethe ProSe capability for building the application functionality. Examplemay be for communication between members of public safety groups or forsocial media application that requests to find buddies in proximity.

The ProSe function in the network (as part of EPS) defined by 3GPP has areference point towards the ProSe application server, towards the EPCand the UE. The functionality may include at least one of followings,but not be restricted thereto.

-   -   Interworking via a reference point towards the 3rd party        applications    -   Authorization and configuration of the UE for discovery and        direct communication    -   Enable the functionality of the EPC level ProSe discovery    -   ProSe related new subscriber data and handling of data storage,        and also handling of ProSe identities    -   Security related functionality    -   Provide control towards the EPC for policy related functionality    -   Provide functionality for charging (via or outside of EPC, e.g.,        offline charging)

Reference points/interfaces in the reference architecture for ProSe aredescribed.

-   -   PC1: It is the reference point between the ProSe application in        the UE and in the

ProSe application server. It is used to define application levelsignaling requirements.

-   -   PC2: It is the reference point between the ProSe application        server and the ProSe function. It is used to define the        interaction between ProSe application server and ProSe        functionality provided by the 3GPP EPS via ProSe function. One        example may be for application data updates for a ProSe database        in the ProSe function. Another example may be data for use by        ProSe application server in interworking between 3GPP        functionality and application data, e.g., name translation.    -   PC3: It is the reference point between the UE and ProSe        function. It is used to define the interaction between UE and        ProSe function. An example may be to use for configuration for        ProSe discovery and communication.    -   PC4: It is the reference point between the EPC and ProSe        function. It is used to define the interaction between EPC and        ProSe function. Possible use cases may be when setting up a        one-to-one communication path between UEs or when validating        ProSe services (authorization) for session management or        mobility management in real time.    -   PC5: It is the reference point between UE to UE used for control        and user plane for discovery and communication, for relay and        one-to-one communication (between UEs directly and between UEs        over LTE-Uu).    -   PC6: This reference point may be used for functions such as        ProSe discovery between users subscribed to different PLMNs.    -   SGi: In addition to the relevant functions via SGi, it may be        used for application data and application level control        information exchange.

FIG. 7 shows an example of one-step ProSe direct discovery procedure.FIG. 7 corresponds to a solution for direct discovery. This solution isbased on mapping application identities to ProSe private expressioncodes in the network. FIG. 7 shows that two UEs are running the sameProSe-enabled application and it is assumed that the users of those UEshave a “friend” relationship on the considered application. The “3GPPLayers” shown in FIG. 7 correspond to the functionality specified by3GPP that enables mobile applications in the UE to use ProSe discoveryservices.

UE-A and UE-B run a ProSe-enabled application, which discovers andconnects with an associated application server in the network. As anexample, this application could be a social networking application. Theapplication server could be operated by the 3GPP network operator or bya third-party service provider. When operated by a third-party provider,a service agreement is required between the third-party provider and the3GPP operator in order to enable communication between the ProSe Serverin the 3GPP network and the application server.

-   1. Regular application-layer communication takes place between the    mobile application in UE-A and the application server in the    network.-   2. The ProSe-enabled application in UE-A retrieves a list of    application-layer identifiers, called “friends”. Typically, such    identifiers have the form of a network access identifier.-   3. The ProSe-enabled application wants to be notified when one of    UE-A's friends is in the vicinity of UE-A. For this purpose, it    requests from the 3GPP layers to retrieve private expressions    codes (i) for the user of UE-A (with an application-layer identity)    and (ii) for each one of his friends.-   4. The 3GPP layers delegate the request to a ProSe server in the    3GPP network. This server can be located either in home PLMN (HPLMN)    or in a visited PLMN (VPLMN). Any ProSe server that supports the    considered application can be used. The communication between the UE    and ProSe server can take place either over the IP layer or below    the IP layer. If the application or the UE is not authorized to use    ProSe discovery, then the ProSe server rejects the request.-   5. The ProSe server maps all provided application-layer identities    to private expression codes. For example, the application-layer    identity is mapped to the private expression code. This mapping is    based on parameters retrieved from the application server in the    network (e.g., mapping algorithm, keys, etc.) thus the derived    private expression code can be globally unique. In other words, any    ProSe server requested to derive the private expression of the    application-layer identity for a specific application, it will    derive the same private expression code. The mapping parameters    retrieved from the application server describe how the mapping    should be done. In this step, the ProSe server and/or the    application server in the network authorize also the request to    retrieve expression codes for a certain application and from a    certain user. It is ensured, for example, that a user can retrieves    expression codes only for his friends.-   6. The derived expression codes for all requested identities are    sent to the 3GPP layers, where they are stored for further use. In    addition, the 3GPP layers notify the ProSe-enabled application that    expression codes for the requested identities and application have    been successfully retrieved. However, the retrieved expression codes    are not sent to the ProSe-enabled application.-   7. The ProSe-enabled application requests from the 3GPP layers to    start discovery, i.e., attempt to discover when one of the provided    “friends” is in the vicinity of UE-A and, thus, direct communication    is feasible. As a response, UE-A announces the expression code of    the application-layer identity for the considered application. The    mapping of this expression code to the corresponding    application-layer identify can only be performed by the friends of    UE-A, who have also received the expression codes for the considered    application.-   8. UE-B also runs the same ProSe-enabled application and has    executed steps 3-6 to retrieve the expression codes for friends. In    addition, the 3GPP layers in UE-B carry out ProSe discovery after    being requested by the ProSe-enabled application.-   9. When UE-B receives the ProSe announcement from UE-A, it    determines that the announced expression code is known and maps to a    certain application and to the application-layer identity. The UE-B    can determine the application and the application identity that    corresponds to the received expression code because it has also    received the expression code for the application-layer identity    (UE-A is included in the friend list of UE-B).

The steps 1-6 in the above procedure can only be executed when the UE isinside the network coverage. However, these steps are not requiredfrequently. They are only required when the UE wants to update or modifythe friends that should be discovered with ProSe direct discovery. Afterreceiving the requested expression codes from the network, the ProSediscovery (steps 7 and 9) can be conducted either inside or outside thenetwork coverage.

It is noted that an expression code maps to a certain application and toa certain application identity. Thus when a user runs the sameProSe-enabled application on multiple UEs, each UE announces the sameexpression code.

FIG. 8 shows an example of two-steps ProSe direct discovery procedure.FIG. 8 corresponds to a targeted ProSe discovery. The present solutionis a “who is there?” type of solution where a user (the “discoverer”)searches to discover a specific target population (the “discoverees”).

-   1. The user of UE1 (the discoverer) wishes to discover whether there    are any members of a specific group communication service enabler    (GCSE) group in proximity. UE1 broadcasts a targeted discovery    request message containing the unique App group ID (or the Layer-2    group ID) of the targeted GCSE group. The targeted discovery request    message may also include the discoverer's unique identifier (App    personal ID of user 1). The targeted discovery request message is    received by UE2, UE3, UE4 and UE5. Apart from the user of UE5, all    other users are members of the requested GCSE group and their UEs    are configured accordingly.-   2a-2c. Each one of UE2, UE3 and UE4 responds directly to UE1 with a    targeted discovery response message which may contain the unique App    personal ID of its user. In contrast, UE5 sends no response message.

In three step procedure, UE1 may respond to the targeted discoveryresponse message by sending a discovery confirm message.

For general design assumption for D2D operation, it is assumed that D2Doperates in uplink spectrum (in the case of frequency division duplex(FDD)) or uplink sub-frames of the cell giving coverage (in case of timedivision duplex (TDD) except when out of coverage). Use of downlinksub-frames in the case of TDD can be studied further. It is assumed thatD2D transmission/reception does not use full duplex on a given carrier.From individual UE perspective, on a given carrier D2D signal receptionand cellular uplink transmission do not use full duplex. Formultiplexing of a D2D signal and cellular signal from an individual UEperspective on a given carrier, frequency division multiplexing (FDM)shall not be used, but time division multiplexing (TDM) can be used.This includes a mechanism for handling/avoiding collisions.

D2D discovery is described. At least the following two types ofdiscovery procedure are defined. However, it is clear that thesedefinitions are intended only to aid clarity for description and not tolimit the scope of the present invention.

-   -   Type 1: a discovery procedure where resources for discovery        signal transmission are allocated on a non UE specific basis.    -   Type 2: a discovery procedure where resources for discovery        signal transmission are allocated on a per UE specific basis.        Resources may be allocated for each specific transmission        instance of discovery signals, or may be semi-persistently        allocated for discovery signal transmission.

Note that further details of how the resources are allocated and bywhich entity, and of how resources for transmission are selected withinthe allocated resources, are not restricted by these definitions.

FIG. 9 to FIG. 12 shows scenarios for D2D ProSe. Referring to FIG. 9 toFIG. 12, UE1 and UE2 are located in coverage/out of coverage of a cell.When UE1 has a role of transmission, UE1 sends discovery message and UE2receives it. UE1 and UE2 can change their transmission and receptionrole. The transmission from UE1 can be received by one or more UEs likeUE2. Table 1 shows more detailed D2D scenarios described in FIG. 9 toFIG. 12.

TABLE 1 Scenarios UE1 UE2 FIG. 9: Out of Coverage Out of Coverage Out ofCoverage FIG. 10: Partial Coverage In Coverage Out of Coverage FIG. 11:In Coverage-Single-Cell In Coverage In Coverage FIG. 12: InCoverage-Multi-Cell In Coverage In Coverage

Referring to Table 1, the scenario shown in FIG. 9 corresponds to a casethat both UE1 and UE2 are out of coverage. The scenario shown in FIG. 10corresponds to a case that UE1 is in coverage, but UE2 is out ofcoverage. The scenario shown in both FIG. 11 and FIG. 12 corresponds toa case that both UE1 and UE2 are in coverage. But, the scenario shown inFIG. 11 corresponds to a case that UE1 and UE2 are both in coverage of asingle cell, while the scenario shown in FIG. 12 corresponds to a casethat UE1 and UE2 are in coverage of multi-cells, respectively, which areneighboring each other.

D2D communication is described. D2D discovery is not a required step forgroupcast and broadcast communication. For groupcast and broadcast, itis not assumed that all receiving UEs in the group are in proximity ofeach other. When UE1 has a role of transmission, UE1 sends data and UE2receives it. UE1 and UE2 can change their transmission and receptionrole. The transmission from UE1 can be received by one or more UEs likeUE2.

D2D relay functionality is described. There are two types of D2D relayfunctionality, i.e. UE-NW relay and UE-UE relay. In UE-NW relay, onenetwork node (e.g. UE) can serve UE-NW relaying functionality for otherUE that is out of network coverage. In UE-UE relay, one network node(e.g. UE) can serve UE-UE relaying functionality for other UEs that areout of coverage each other/one another.

FIG. 13 shows an example of UE-NW relay functionality. Referring to FIG.13, UE1 cannot communicate with base station without UE2 that can serveUE-NW relay functionality for UE1. Accordingly, UE1 can communicate withbase station with UE2 that serves relay functionality for UE1.

FIG. 14 shows an example of UE-UE relay functionality. UE1 cannotcommunicate with UE3 without UE2 that can serve UE-UE relayfunctionality for UE1 and UE3.

Accordingly, UE1 can communicate with UE3 with UE2 that serves UE-UErelay functionality for UE1 and UE3.

Sidelink is UE to UE interface for ProSe direct communication and ProSedirect discovery. Sidelink comprises ProSe direct discovery and ProSedirect communication between UEs. Sidelink uses uplink resources andphysical channel structure similar to uplink transmissions. Sidelinktransmission uses the same basic transmission scheme as the ULtransmission scheme. However, sidelink is limited to single clustertransmissions for all the sidelink physical channels. Further, sidelinkuses a 1 symbol gap at the end of each sidelink sub-frame.

FIG. 15 shows an example of mapping between sidelink transport channelsand sidelink physical channels. Referring to FIG. 15, a physicalsidelink discovery channel (PSDCH), which carries proSe direct discoverymessage from the UE, may be mapped to a sidelink discovery channel(SL-DCH). The SL-DCH is characterized by:

-   -   fixed size, pre-defined format periodic broadcast transmission;    -   support for both UE autonomous resource selection and scheduled        resource allocation by eNB;    -   collision risk due to support of UE autonomous resource        selection; no collision when UE is allocated dedicated resources        by the eNB.

A physical sidelink shared channel (PSSCH), which carries data from a UEfor ProSe direct communication, may be mapped to a sidelink sharedchannel (SL-SCH). The SL-SCH is characterized by:

-   -   support for broadcast transmission;    -   support for both UE autonomous resource selection and scheduled        resource allocation by eNB;    -   collision risk due to support of UE autonomous resource        selection; no collision when UE is allocated dedicated resources        by the eNB;    -   support for HARQ combining, but no support for HARQ feedback;    -   support for dynamic link adaptation by varying the transmit        power, modulation and coding.

A physical sidelink broadcast channel (PSBCH), which carries system andsynchronization related information transmitted from the UE, may bemapped to a sidelink broadcast channel (SL-BCH). The SL-BCH ischaracterized by pre-defined transport format. A physical sidelinkcontrol channel (PSCCH) carries control from a UE for ProSe directdommunication.

FIG. 16 shows an example of mapping between sidelink logical channelsand sidelink transport channels for ProSe direct communication.Referring to FIG. 16, the SL-BCH may be mapped to a sidelink broadcastcontrol channel (SBCCH), which is a sidelink channel for broadcastingsidelink system information from one UE to other UE(s). This channel isused only by ProSe direct communication capable UEs. The SL-SCH may bemapped to a sidelink traffic channel (STCH), which is apoint-to-multipoint channel, for transfer of user information from oneUE to other UEs. This channel is used only by ProSe direct communicationcapable UEs.

A protocol data unit (PDU) is described. It may be referred to Section 6of 3GPP TS 36.321 V11.3.0 (2013-06). A MAC PDU is a bit string that isbyte aligned (i.e. multiple of 8 bits) in length. MAC service data units(SDUs) are bit strings that are byte aligned (i.e. multiple of 8 bits)in length. An SDU is included into a MAC PDU from the first bit onward.The UE shall ignore the value of reserved bits in downlink MAC PDUs.

FIG. 17 shows an example of a MAC PDU. A MAC PDU consists of a MACheader, zero or more MAC control elements (CEs), zero or more MAC SDUs,and optionally padding. Both the MAC header and the MAC SDUs are ofvariable sizes.

FIG. 18 to FIG. 20 shows an example of a MAC PDU subheader. A MAC PDUheader consists of one or more MAC PDU subheaders. Each subheadercorresponds to either a MAC SDU, a MAC CE or padding. A MAC PDUsubheader consists of the six header fields R/R/E/LCID/F/L but for thelast subheader in the MAC PDU and for fixed sized MAC CEs. FIG. 18 showsR/R/E/LCID/F/L MAC PDU subheader with 7-bits L field. FIG. 19 showsR/R/E/LCID/F/L MAC PDU subheader with 15-bits L field. The lastsubheader in the MAC PDU and subheaders for fixed sized MAC CEs consistsolely of the four header fields R/R/E/LCID. A MAC PDU subheadercorresponding to padding consists of the four header fields R/R/E/LCID.FIG. 20 shows R/R/E/LCID MAC PDU subheader. MAC PDU subheaders have thesame order as the corresponding MAC SDUs, MAC CEs and padding.

MAC CEs are always placed before any MAC SDU. Padding occurs at the endof the MAC PDU, except when single-byte or two-byte padding is required.Padding may have any value and the UE shall ignore it. When padding isperformed at the end of the MAC PDU, zero or more padding bytes areallowed. When single-byte or two-byte padding is required, one or twoMAC PDU subheaders corresponding to padding are placed at the beginningof the MAC PDU before any other MAC PDU subheader. A maximum of one MACPDU can be transmitted per transport block (TB) per UE. A maximum of oneMCH MAC PDU can be transmitted per TTI.

The MAC header is of variable size and consists of the following fields:

-   -   LCID (logical channel ID): The LCID field identifies the logical        channel instance of the corresponding MAC SDU or the type of the        corresponding MAC CE or padding. There is one LCID field for        each MAC SDU, MAC CE or padding included in the MAC PDU. In        addition to that, one or two additional LCID fields are included        in the MAC PDU, when single-byte or two-byte padding is required        but cannot be achieved by padding at the end of the MAC PDU. The        LCID field size is 5 bits. Table 2 shows an example of values of        LCID for DL-SCH. Table 3 shows an example of values of LCID for        UL-SCH Table 4 shows an example of values of LCID for MCH.

TABLE 2 Index LCID values 00000 CCCH 00001-01010 Identity of the logicalchannel 01011-11010 Reserved 11011 Activation/Deactivation 11100 UEContention Resolution Identity 11101 Timing Advance Command 11110 DRXCommand 11111 Padding

TABLE 3 Index LCID values 00000 CCCH 00001-01010 Identity of the logicalchannel 01011-11000 Reserved 11001 Extended Power Headroom Report 11010Power Headroom Report 11011 C-RNTI 11100 Truncated BSR 11101 Short BSR11110 Long BSR 11111 Padding

TABLE 4 Index LCID values 00000 MCCH (see note) 00001-11100 MTCH 11101Reserved 11110 MCH Scheduling Information 11111 Padding NOTE: If thereis no MCCH on MCH, an MTCH could use this value.

-   -   L (length): The L field indicates the length of the        corresponding MAC SDU or variable-sized MAC CE in bytes. There        is one L field per MAC PDU subheader except for the last        subheader and subheaders corresponding to fixed-sized MAC CEs.        The size of the L field is indicated by the F field.    -   F (format): The F field indicates the size of the L field. There        is one F field per

MAC PDU subheader except for the last subheader and subheaderscorresponding to fixed-sized MAC CEs. The size of the F field is 1 bit.If the size of the MAC SDU or variable-sized MAC CE is less than 128bytes, the value of the F field is set to 0, otherwise it is set to 1.Table 5 shows an example of values of F field.

TABLE 5 Index Size of Length field (in bits) 0 7 1 15

-   -   E (extension): The E field is a flag indicating if more fields        are present in the MAC header or not. The E field is set to “1”        to indicate another set of at least R/R/E/LCID fields. The E        field is set to “0” to indicate that either a MAC SDU, a MAC CE        or padding starts at the next byte;    -   R: Reserved bit, set to “0”.

The MAC header and subheaders are octet aligned.

Currently, when UE2 receives D2D data from UE1, UE2 cannot recognizequality of service (QoS) of the received D2D data. Thus, it may bedifficult that UE2 properly handles the received D2D data based on QoSof the received D2D data.

In order to solve the problem described above, a method for indicatingQoS of D2D data according to an embodiment of the present invention isdescribed below. According to an embodiment of the present invention, afirst UE may determine a value of a field in a header in a layer 2 PDUbased on QoS of D2D data, and transmit the layer 2 PDU to a second UE.The second UE may identify the QoS of the D2D data based on the value ofthe field in the header in the layer 2 PDU. Accordingly, the UE2receiving D2D data can properly handle the received D2D data based onQoS of the received D2D data.

FIG. 21 shows an example of a method for indicating QoS of D2D dataaccording to an embodiment of the present invention.

In step S100, UE1 identifies D2D data to be directly transmitted over aradio bearer to one or more UEs, including UE2. The radio bearer may bea D2D radio bearer, and the D2D radio bearer may be a sidelink radiobearer. Further, UE1 identifies QoS of the D2D data. For example, if theD2D data corresponds to voice, QoS corresponding to voice may beidentified. If the D2D data corresponds to video, QoS corresponding tovideo may be identified. If the D2D data corresponds to text or image,QoS corresponding to background data may be identified.

In step S110, UE1 determines a value of a field in a header in a layer 2PDU based on the identified QoS. The value of the field indicates QoS ofthe D2D data over the radio bearer to UE2. For example, if the D2D datacorresponds to voice, the value of the field may be set to 1. If the D2Ddata corresponds to video, the value of the field may be set to 2. Ifthe D2D data corresponds to text or image, the value of the field mayset to 3. If the D2D data corresponds to emergency call or high prioritycall, the value of the field may set to 0. Those values are known to allUEs involving D2D communications. The field may be one of a LCID, asource ID, a target ID and a group ID in a layer 2 header. The layer 2header may a MAC header. The layer 2 PDU may correspond to the D2D dataover the radio bearer. The layer 2 PDU may be a MAC PDU.

In step S120, UE1 constructs the layer 2 PDU, and transmits theconstructed layer 2

PDU to one or more UEs, including UE2, over the radio bearer based onthe identified QoS. If the layer 2 PDU is MAC PDU, UE1 constructs theMAC PDU, with the MAC header and MAC SDU, for the D2D data over theradio bearer. The MAC header may include one or more fields such assource ID, target ID, group ID, and LCID, which has the value determinedin step S110.

Upon receiving the layer 2 PDU from UE1 over the radio bearer, in stepS130, UE2 acquires a header in the received layer 2 PDU, and identifiesQoS of the received D2D data over the radio bearer based on the acquiredheader. That is, UE2 identifies QoS of the D2D data over the radiobearer based on the value of the field in the acquired header. The fieldmay be one of a LCID, a source ID, a target ID and a group ID of theacquired header. UE2 may already understand meaning of the value of thefield, i.e. mapping relationship between the value of the field and QoS.For example, 3GPP specification may specify the mapping relationshipbetween the value of the field and QoS. Alternatively, the network mayindicate the mapping relationship between the value of the field and QoSto UE2. In this case, the mapping relationship may be indicated, e.g.during NAS procedure such as attach procedure or routing area updateprocedure, or RRC procedures such as RRC connection establishmentprocedure, RRC connection reconfiguration procedure or RRC connectionre-establishment procedure. Alternatively, UE1 may indicate the mappingrelationship to UE2 before transmitting the D2D data.

UE2 may transfer the received layer 2 PDU to the network based on theidentified QoS of the D2D data over the radio bearer. For example, whenUE2 transfers the received layer 2 PDU to the network, UE2 mayprioritize transmission of data corresponding to voice or emergency callbased on the identified QoS of the D2D data. On the other hand, UE2 mayde-prioritize transmission of data corresponding to text or image basedon the identified QoS of the D2D data.

FIG. 22 shows a wireless communication system to implement an embodimentof the present invention.

An eNB 800 may include a processor 810, a memory 820 and a radiofrequency (RF) unit 830. The processor 810 may be configured toimplement proposed functions, procedures and/or methods described inthis description. Layers of the radio interface protocol may beimplemented in the processor 810. The memory 820 is operatively coupledwith the processor 810 and stores a variety of information to operatethe processor 810. The RF unit 830 is operatively coupled with theprocessor 810, and transmits and/or receives a radio signal.

A UE 900 may include a processor 910, a memory 920 and a RF unit 930.The processor 910 may be configured to implement proposed functions,procedures and/or methods described in this description. Layers of theradio interface protocol may be implemented in the processor 910. Thememory 920 is operatively coupled with the processor 910 and stores avariety of information to operate the processor 910. The RF unit 930 isoperatively coupled with the processor 910, and transmits and/orreceives a radio signal.

The processors 810, 910 may include application-specific integratedcircuit (ASIC), other chipset, logic circuit and/or data processingdevice. The memories 820, 920 may include read-only memory (ROM), randomaccess memory (RAM), flash memory, memory card, storage medium and/orother storage device. The RF units 830, 930 may include basebandcircuitry to process radio frequency signals. When the embodiments areimplemented in software, the techniques described herein can beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. The modules can be stored inmemories 820, 920 and executed by processors 810, 910. The memories 820,920 can be implemented within the processors 810, 910 or external to theprocessors 810, 910 in which case those can be communicatively coupledto the processors 810, 910 via various means as is known in the art.

In view of the exemplary systems described herein, methodologies thatmay be implemented in accordance with the disclosed subject matter havebeen described with reference to several flow diagrams. While forpurposed of simplicity, the methodologies are shown and described as aseries of steps or blocks, it is to be understood and appreciated thatthe claimed subject matter is not limited by the order of the steps orblocks, as some steps may occur in different orders or concurrently withother steps from what is depicted and described herein. Moreover, oneskilled in the art would understand that the steps illustrated in theflow diagram are not exclusive and other steps may be included or one ormore of the steps in the example flow diagram may be deleted withoutaffecting the scope and spirit of the present disclosure.

What is claimed is:
 1. A method for a user equipment (UE) indicatingquality of service (QoS) of device-to-device (D2D) data in a wirelesscommunication system, the method performed by the UE and comprising:identifying the QoS of the D2D data over a radio bearer; receiving amapping relationship between a value of a field in a header of a layer 2protocol data unit (PDU) and the QoS from a network; determining thevalue of the field based on the identified QoS according to the receivedmapping relationship; and transmitting the layer 2 PDU to a differentUE, the PDU including the header, wherein the field is a logical channelidentifier (LCID), a source ID, a target ID or a group ID in a MACheader.
 2. The method of claim 1, wherein the PDU is a media accesscontrol (MAC) PDU.
 3. The method of claim 1, wherein the radio bearer isa D2D radio bearer.
 4. The method of claim 3, wherein the D2D radiobearer is a sidelink radio bearer.
 5. The method of claim 1, furthercomprising identifying the D2D data for direct transmission over theradio bearer to the different UE.
 6. A method for a user equipment (UE)identifying quality of service (QoS) of device-to-device (D2D) data in awireless communication system, the method performed by the UE andcomprising: receiving a layer 2 protocol data unit (PDU) from adifferent UE over a radio bearer, the PDU including a header including afield; receiving a mapping relationship between a value of the field andthe QoS from a network; and identifying the QoS based on the value ofthe field in the header according to the received mapping relationship,wherein the field is a logical channel identifier (LCID), a source ID, atarget ID or a group ID in a MAC header, and wherein the value of thefield is determined based on the QoS according to the received mappingrelationship.
 7. The method of claim 6, wherein the PDU is a mediaaccess control (MAC) PDU.
 8. The method of claim 6, wherein the radiobearer is a D2D radio bearer.
 9. The method of claim 8, wherein the D2Dradio bearer is a sidelink radio bearer.
 10. The method of claim 6,further comprising transmitting the received layer 2 PDU to a networkbased on the identified QoS.
 11. The method of claim 6, furthercomprising receiving information related to a mapping relationshipbetween the identified QoS and the value of the field.
 12. The method ofclaim 11, wherein the information is received during a non-accessstratum (NAS) procedure or a radio resource control (RRC) procedure. 13.The method of claim 6, further comprising receiving information relatedto a mapping relationship between the identified QoS and the value ofthe field from the different UE before receiving the layer 2 PDU.